The present invention relates to the field of communications in general and more particularly, to the provisioning of a mobile terminal device.
Increasingly, mobile terminal devices, such as radiotelephones, personal digital assistants (PDAs) and the like, have incorporated data capabilities such as web browsing and/or e-mail receipt and generation. One technique for providing such data capabilities to mobile devices is through the use of the Internet Protocol (IP) over a wireless communications medium. Typically, the use of IP packet data communications in a wireless environment takes one of two forms, simple IP where communications to a mobile device either occur within a single subnet or the device logs on to each subnet individually when it is moved to that subnet or mobile IP (MIP) where a mobile device utilizes a home agent to communicate with the Internet and may move between multiple subnets, without logging on to each subnet, by registering with a foreign agent. Details of the MIP standard are provided in the IETF RFC-2002 on mobility support and the MIP adaptation for Code Division Multiple Access (CDMA) wireless communications are provided in the Wireless IP Network Standard, TIA/EIA IS-835.
A mobile device utilizing MIP typically registers with a foreign agent and obtains a lease for a session established between the foreign agent and the mobile device. The lease, typically, has a fixed duration, for example, a 2 hour duration. Typically, prior to the lease expiring, the mobile terminal will renew the lease. For example, a lease is generally renewed between 0 and 60 minutes before the lease expires and, typically, about 30 minutes before the lease expires. The foreign agent forwards data received from the home agent to the mobile device and may forward data received from the mobile device to the home agent. Typically, the home agent acts as an access point to the Internet such that all IP communications with the mobile device pass through the home agent. The foreign agent, typically, performs the forwarding function for the duration of the lease if the mobile device has a registered MIP session with the foreign agent.
In a conventional MIP system, a mobile device may be provided with authentication, validation, feature and/or other data in a process known as “provisioning.” Typically, the process is initially performed when the mobile device is placed in service. This initial provisioning will, typically, establish a default network access information (NAI) profile and provide feature configuration for the mobile device. This initial provisioning is often referred to as network initiated initial provisioning (NIIP). Changes to the information that is provided by provisioning a mobile device, for example, to change a username or password for network access, are typically provided as part of a network initiated subsequent provisioning (NISP) operation.
Typically, a NISP trigger request is transmitted to a mobile device utilizing a short message service (SMS) message. When the mobile device receives the NISP request, the mobile device establishes a MIP session utilizing the default NAI profile and obtains the new provisioning data. This provisioning data may change the information in the default NAI profile or other NAI profiles utilized by the mobile device, such as a custom NAI profile. For example, in a typical system, a mobile device uses a custom NAI profile for user-initiated data applications, such as web browsing or executing a Java 2 Platform, Micro Edition (J2ME) MID1et. A user, however, may change their username or password by changing this information via a browser interface. This information will, typically, be updated at the network, for example, at an authentication, authorization and accounting server, and a NISP request may be sent to the mobile device so that the information stored in the mobile device may be updated. Typically, the NISP request is sent as an SMS message to the mobile device. The mobile device then establishes a session using its default NAI profile and obtains the updated provisioning information.
One difficulty that may arise in a system that utilizes multiple NAI profiles but which may only maintain one MIP session at a time occurs if a NISP request is received during a MIP session established using the custom NAI profile. To immediately process the NISP request, the mobile device would generally need to terminate the current MIP session and establish a MIP session using the default NAI profile. Such a termination may be intrusive and/or confusing to the user as it could disrupt the session of the user application without the user knowing the cause of the disruption. Furthermore, if the NISP request is discarded by the mobile device, so as to not disrupt the session of the user application, the NISP request will generally not be resent by the network without further intervention by the user. Such is the case because the NISP request is typically received as an SMS message that is acknowledged as received by the mobile device. Furthermore, after some period of time, for example, 72 hours, without receiving a response the NISP request the service provider typically discards the new requested changes. Thus, the user may need to repeat all of the changes and the provisioning update reinitiated by the service provider or a call to customer service may be required.
One proposed solution to the above described problem is to queue the NISP request. The NISP request would then be carried out if no keystroke was received for a predefined time interval, such as 1 minute, or if no data packets were sent or received for a second predefined time interval, such as 1 minute. While such an approach may reduce the intrusiveness of carrying out the NISP request, it may create implementation difficulties in the management of multiple timers in disparate logical blocks in a coordinated fashion. Furthermore, such a solution does not take into account the need for the mobile device to periodically perform a MIP re-registration. If the response to the NISP request is delayed until after a MIP re-registration is required, the re-registration will, typically, fail as the old parameters may be utilized that are out of sync with the network infrastructure.